REMARKS 

This is a full and timely response to the outstanding non-final Office Action 
mailed November 17, 2003. Reconsideration and allowance of the application and 
pending claims are respectfully requested. 

I. Claim Rejections - 35 U-S.C. § 103(a) 

A. Rejection of Claims 22, 27-28, and 32-33 

1 . Statement of the Rejection 

Claims 22, 27-28, and 32-33 have been rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Varma (U.S. Patent No. 6,336,134) in view of Smith, et al . 
("Smith," U.S. Pat. No. 6,282,564). 

The rejection alleges that Varma discloses Applicant's invention substantially as 
claimed with the exception of (i) sending an inquiry to remote applications requesting 
notification when the remote applications are ready to receive events, and (ii) 
transmitting the events to the remote applications when the remote applications indicate 
a ready-to-receive status. The rejection concludes, however, that in view of the Smith 
disclosure, it would have been obvious to a person having ordinary skill in the art to add 
those features to the Varma system. Applicant respectfully traverses this rejection, 

2. The Varma Reference 

Varma discloses a system and method for synchronizing modifications to 
facilitate real-time collaboration. As is described by Varma with reference to Figure 3, 
the system includes multiple partition servers 3 1 and a collaboration server 32. Varma , 
column 7, lines 32-39. Collectively, the partition servers 31 are similar in function to a 
centralized server used in prior art systems described by Varma in relation to FIG. 1 . Id. 



at lines 64-67. Therefore, the partition servers receive and share modifications sent to 
them by cHents. The partition servers, however, are assigned different "partitions" that 
may be modified. Id. at column 5, lines 39-63. The partitions pertain to different 
portions of a given document. Id. For example, one partition server may be associated 
with particular paragraphs of a text document, tables of a spreadsheet document, or 
objects of a drawing. Id. 

The partition servers each include a first-in-first-out (FIFO) "queue" (not 
"buffer") in which modifications to be distributed to the various clients are ordered. IdL 
at column 7, line 64 to column 8, line 3. The partition servers to determine what 
modifications distribute to the clients based upon the order identified in the queue. Id. at 
column 8, line 4 to column 10, line 35. That order is "channel-order preserving" to , 
provide a reasonable amount of fairness in modification distribution. Id. 

3. Discussion of the Rejection 

As acknowledged by the Court of Appeals for the Federal Circuit, the U.S. 
Patent and Trademark Office ("USPTO") has the burden under section 103 to establish a 
proper case of obviousness by showing some objective teaching in the prior art or 
generally available knowledge of one of ordinary skill in the art that would lead that 
individual to the claimed invention. See h\ re Fine , 837 F.2d 1071, 5 U.S.P.Q.2d 1596, 
1598 (Fed. Cir. 1988). Accordingly, to make a proper case for obviousness, there must 
be some prior art teaching or established knowledge that would suggest to a person 
having ordinary skill in the pertinent art to fill the voids apparent in the applied 
reference. It is respectfully asserted that no such case has been made in the outstanding 
Office Action against Applicant's claims. Each of Applicant's independent claims are 
discussed separately in the following. 
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(a) Independent Claim 22 

Claim 22 provides as follows: 

22. A system for ensuring synchronization of multiple 
applications at remote locations, the system comprising: 

local application sharing logic configured to receive events 
to be shared from a plurality of local applications, the local 
application sharing logic further configured to transmit the 
events; remote application sharing logic configured to 
receive events from the local application sharing logic; and 

remote event buffering logic configured to buffer events 
received by the remote application sharing logic, the remote 
event buffering logic further configured to determine if 
remote applications are ready to receive the events by sending 
an inquiry to the remote applications requesting notification 
when the remote applications are ready to receive the events; 

the remote application sharing logic further configured to 
transmit events to the remote applications when the remote 
applications indicate a ready-to-receive status in response to 
the inquiry, 
(emphasis added). 

As a first matter, Applicant notes that, although the Office Action states that 
Varma teaches each of "local application sharing logic" and "remote application sharing 
logic" and generally cites passages of the Varma reference's text, the Office Action does 
not identify those claimed features with particularity. For instance, is the Office Action 
alleging that Varma's partition servers comprise the "local application sharing logic" or 
is it Varma's distribution server that allegedly comprises that logic? Furthermore, what 
component of Varma's system comprises the "remote application sharing logic"? 



Without such details, it is impossible for Applicant to effectively rebut the rejection. In 
other words, without a clear statement as to what aspects of Varma's system specifically 
account for each of Applicant's explicit claim limitations. Applicant is deprived a full 
and fair opportunity to respond to the rejection. 

Irrespective of the ambiguity of the outstanding rejection, it is clear that Varma's 
system does not comprise "remote event buffering logic configured to buffer events 
received by the remote application sharing logic" as is required by claim 22. First, as 
noted above, it is not clear what component or feature of Varma's system is being 
alleged to comprise "remote application sharing logic". Accordingly, it is difficult to 
respond to an allegation that Varma teaches buffering logic configured to buffer 
events received by that remote application sharing logic. Regardless, Varma simply 
does not teach "remote event buffering logic" as the following discussion elucidates. ^ 

As described above, Varma discloses a system that includes multiple partition - 
servers that each include a FIFO "queue" which is used to assign an order to . 
modifications to be distributed to the various clients. As is known by persons having ^ 
ordinary skill in the art, a "queue" is not the same as a "buffer." Although both can 
contain data, the term "queue" merely pertains to an ordered list. As defined by 
webepedia, a continually-updated computer and Internet terminology dictionary, 
"queue" (as a noun) means: 

n.) (1) A group of jobs waiting to be executed. (2) In 
programming , a queue is a data structure in which elements are 
removed in the same order they were entered. This is ofl;en 
referred to as FIFO (first in, first out). In contrast, a stack is a 
data structure in which elements are removed in the reverse 
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order from which they were entered. This is referred to as LIFO 
(last in, first out). 

webopedia.com , pubhshed November 7, 2003 

Therefore, as described above, Varma's partition servers receive modifications 
and those modifications (really identifiers for those modifications) are placed in the 
queue or list so that the partition servers know which modification to distribute next. 
Compare that with the term "buffer," which is defined (as a noun) as provided in the 
following: 

n.) A temporary storage area, usually in RAM . The purpose of 
most buffers is to act as a holding area, enabling the CPU to 
manipulate data before transferring it to a device . 
Because the processes of reading and writing data to a disk are 
relatively slow, many programs keep track of data changes in a 
buffer and then copy the buffer to a disk. For example, word 
processors employ a buffer to keep track of changes to files . 
Then when you save the file, the word processor updates the 
disk file with the contents of the buffer. This is much more 
efficient than accessing the file on the disk each time you make 
a change to the file. 

Note that because your changes are initially stored in a buffer, 
not on the disk, all of them will be lost if the computer fails 
during an editing session. For this reason, it is a good idea to 
save your file periodically. Most word processors automatically 
save files at regular intervals. 

From the above, it is clear that, unlike a mere order of items to execute (i.e., a 
data structure), a buffer is a temporary storage area. The distinction is significant. 
Specifically, although Varma states that modifications are "placed in the queue," the 
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queue does not actually store the modifications because a queue is only a list that is 
consulted when deciding which modification to send. In contrast, a buffer is a storage 
area (e.g., region of memory) in which the data (e.g., a "modification" or an "event") is 
actually stored. Therefore, although a queue such as Varma's FIFO queue can comprise 
a nearly endless list that identifies the order of modifications to distribute, a buffer, such 
as that claimed by AppHcant, will only be able to contain a finite amount (as dictated by 
the size of the buffer) of actual event data. 

hi view of the above, it is not proper to simply equate a "queue" with a "buffer." 
Given that these two features are indeed distinct, the Office Action must either identify a 
buffer in the Varma system that buffers events received by remote application sharing 
logic or identify a suggestion for such a buffer in Varma or another prior art reference. 
Given that neither Varma nor Smith comprises such a suggestion, the rejection fails to 
render Applicant's claim 22 obvious. 

As is acknowledged in the Office Action, Varma further fails to disclose remote 
event buffering logic "configured to determine if remote applications are ready to 
receive the events by sending an inquiry to the remote applications requesting 
notification when the remote applications are ready to receive the events" and remote 
application sharing logic "configured to transmit events to the remote applications 
when the remote applications indicate a ready-to-receive status in response to the 
inquiry". To account for these deficiencies of the Varma reference, the Office Action 
identifies the Smith reference, which is alleged to suggest adding such features to the 
Varma system. 

As a first matter. Applicant notes that, as discussed above, Varma fails to teach 
remote event buffering logic as is recited in claim 22. In view of the fact that Smith 
likewise fails to teach such a feature. Smith cannot account for that shortcoming and, 
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therefore, Varma in view of Smith cannot render AppHcant^s claim 22 obvious. 
Irrespective of that fact, AppHcant discusses the Smith disclosure in the following. 

Smith discloses a method, system, and apparatus that pertain to "the exchange of 
stored information between a Stored Program Computer System (SPCS), such as located 
at a telephone company central office or elsewhere, and Customer Premises Equipment 
(CPE), such as an appropriately enable telephone. Smith , column 1, lines 7-11. Given 
that fact, it is not surprising that Smith says nothing about synchronizing data or 
partitioning documents. Accordingly, as a first matter, it is questionable whether the 
Smith reference is properly combinable with the Varma reference. Specifically, Smith 
and Varma appear to address distinct areas of technology and a person having ordinary 
skill in the art of data synchronization would not think to consult the Smith reference ^ 
(which pertains to exchanges between telephone companies and their customers) to ^ 
modify Varma's system. 

hrespective of whether the Varma and Smith references pertain to analogous., 
areas of art, there is simply no motivation to add the aspect of determining if remote ^ 
applications are ready to receive events to the Varma system. As has been well 
established in the law, teachings of references can be combined only if there is some 
suggestion or incentive to do so. ACS Hospital Systems, Inc. v. Montefiore Hospital , 
732 R2d 1572, 1577, 221 U.S.P.Q. 929, 933 (Fed. Cir. 1984). In this case, it is clear 
that Varma says nothing about determining if remote applications are ready to receive 
events by sending an inquiry to the remote applications. Furthermore, Smith contains 
no suggestion that such a step could be used in a synchronization system such as 
Varma's system. Without such an appropriate suggestion provided by either 
reference, the rejection cannot comprise a proper rejection under 35 U.S.C. § 103(a). 
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(b) Independent Claim 27 

Claim 27 provides as follows: 

27. A method for ensuring synchronization of multiple 
applications at remote locations, the method comprising: 

transmitting events to be shared from a plurality of local 
applications; 

receiving events in a local application sharing logic, 
transmitting the events from the local application sharing 
logic; 

receiving events, transmitted from the local application sharing 
logic, using remote application sharing logic; 

buffering the events received in the remote application 
sharing logic; 

determining if a plurality of remote applications are ready ^^V 
to receive the events by sending an inquiry to the remote 
applications requesting notification when the remote 
applications are ready to receive the events; and 

transmitting the events from the remote application 
sharing logic to the remote applications when the remote 
applications are ready to receive the events, 
(emphasis added). 

Applicant first notes that the Office Action has not identified within the Varma 
reference "local application sharing logic" or "remote application sharing logic", as 
noted above in relation to claim 22. 

As a fiirther point, in that Varma only teaches a FIFO queue, Varma does not 
teach "buffering the events received in the remote application sharing logic" as is 
required by claim 27. Applicant refers the Examiner to the discussion regarding claim 
22. 
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As is acknowledged in the Office Action, Varma fails to disclose "determining 
if a plurality of remote applications are ready to receive the events by sending an 
inquiry to the remote applications requesting notification when the remote 
applications are ready to receive the events" as is required by claim 27. Applicant 
submits that the proferred combination of Varma and Smith does not render that 
aspect obvious and refers the Examiner to the discussion provided above regarding 
claim 22. 

Given that the Varma/Smith combination does not render obvious 
"determining if a plurality of remote applications are ready to receive the events by 
sending an inquiry to the remote applications requesting notification when the remote 
applications are ready to receive the events" it logically follows that Varma/Smith 
does not render obvious transmitting the events from the remote application sharing 
logic to the remote applications when the remote applications are ready to receive the 
events". 

(c) Independent Claim 32 

Claim 32 provides as follows: 

32. A system for ensuring synchronization of multiple 
applications at remote locations, said system comprising: 

means for transmitting events to be shared from a plurality 
of local applications; 

means for receiving events in a local application sharing 
logic, 

means for transmitting the events from the local application 
sharing logic; 
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means for receiving events, transmitted from the local 
application sharing logic, in a remote application sharing 
logic, 

means for buffering the events received in the remote 
application sharing logic; 

means for determining if a plurality of remote 
applications are ready to receive the events by sending an 
inquiry to the remote applications requesting notification when 
the remote applications are ready to receive the events; and 

means for transmitting the events from the remote 
application sharing logic to the remote applications when the 
remote applications are ready to receive the events. 
(emphasis added) 

Applicant first notes that the Office Action does not identify in the Varma> 
reference "local application sharing logic" or "remote application sharing logic" with;.^ 
particularity. Applicant refers the Examiner to the discussion of claim 22. 

Moreover, the proffered combination does not properly suggest a system for • 
ensuring synchronization including any of "means for buffering the events received in 
the remote application sharing logic", "means for determining if a plurality of remote 
applications are ready to receive the events by sending an inquiry to the remote 
applications requesting notification when the remote applications are ready to receive 
the events", or "means for transmitting the events from the remote application sharing 
logic to the remote applications when the remote applications are ready to receive the 
events" for reasons discussed above in relation to claim 22. 
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B. Rejection of Claims 24-26, 29-31, and 34-36 
1- Statement of the Rejection 

Claims 24-26, 29-31, and 34-36 have been rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Varma and Smith in view of Hales, et al. ("Hales," U.S. Pat. 
No. 5,938,723). 

2. Discussion of the Rejection 

As identified above, the proffered Varma/Smith combination is insufficient to 
render Applicant's claims 22, 27-28, and 32-33 obvious. Given that Hales does not 
remedy the deficiencies of the Varma/Smith combination. Applicant respectfiilly 
submits that claims 24-26, 29-31, and 34-36 are likewise unobvious, and therefore 
allowable, for at least the reasons discussed in the foregoing. 

II. New Claims 

As identified above, claims 37-53 have been added into the application through 
this response. Applicant respectfully submits that these new claims describe an 
invention novel and unobvious in view of the prior art of record and, therefore, 
respectfully requests that these claims be held to be allowable. 

III. Office Action Submission 

Applicant submits herewith an Office Action (Attachment "A") received in 
application serial no. 09/507,435 for consideration of the Examiner. 
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CONCLUSION 



Applicant respectfully submits that Applicant's pending claims are in 
condition for allowance. Favorable reconsideration and allowance of the present 
application and all pending claims are hereby courteously requested. If, in the opinion 
of the Examiner, a telephonic conference would expedite the examination of this matter, 
the Examiner is invited to call the undersigned attomey at (770) 933-9500. 



I hereby certify that this correspondence is being 
deposited with the United States Postal Service as 
first class mail, postage prepaid, in an envelope 
addressed to: Assistant Commissioner for Patents, 
Alexandria, Virginia 22313-1450, on 



Respectfully submitted, 
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